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1 PRESILICON DISK MODEL FOR DESIGN, DEVELOPMENT AND VALIDATION 

2 

3 BACKGROUND OF THE INVENTION 

4 Field of the Invention 

5 The present invention relates to disk drives. More particularly, the present invention relates 

6 to a presilicon disk model of a disk drive for design, development and validation purposes and 

7 methods for vaUdating tiie design of a disk controller circuit to be incorporated into a targeted hard 

8 disk drive system. 

9 Description of the Prior Art 

10 Time to market considerations and the fiercely competitive nature of the disk drive 

11 industry have led to increased pressures to accelerate the development of each subsequent 

12 generation of hard drives. Designing, prototyping and vahdating a new product, however, is time 

13 consuming and costly. The storage industry, therefore, has been seeking for methods of more 

14 efficiently bringing new products to market. Simulations provide a relatively inexpensive 

15 method of developing, testing and validating new disk drives. Simulation is the process of using 

16 software and/or programmable hardware to model electronic systems. Because it is expensive 

17 and time consuming to build silicon devices, simulation is used extensively before fabrication to 

18 verify that devices will work properly. Previous models and simulations, however, only modeled 

19 a few selected functions of the hard drive, and did not do so with the same timing as a real hard 

20 drive and did so only with extensively modified firmware. 

21 However, imless all of the major components of a hard drive are modeled and emulated 

22 (with the correct timing), the usefubiess of the pre-silicon testing and validation diminishes, as 

23 extensive modifications to the drive's firmware must be carried out to account for the less than 

24 complete and/or accurate simulation. In tum, as the simulation's firmware does not correspond 

25 to the firmware to be ultimately incorporated in the real drive, additional extensive testing must 

26 be carried out on the physical drive to validate the underlying design. What are needed, 

27 therefore, are methods and systems for simulating entire drives while maintaining the accurate 

28 timing of the operation of the various components thereof. Such methods and systems would 
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enable the design, testing and validation of entire disk drives using the same (or only minimally- 

2 modified) firmware as will be incorporated in the resulting physical disk drive. 

3 SUMMARY OF THE INVENTION 

4 Accordingly, this invention may be regarded as a method for verifying the design of a 

5 disk controller circuit to be incorporated into a targeted hard disk drive system, wherein the 

6 targeted hard disk drive system comprises a read/write channel and a head actuator. The method 

7 includes the steps of emulating reading and writing of data in the read/write channel based upon 

8 a model of the read/write channel; emulating a behavior of the head actuator during track seek 

9 and track following operations based upon an electromechanical model of the head actuator; 

10 providing a disk controller design base for defining integrated circuit elements comprising the 

11 disk controller circuit; providing a controller environment to support execution and debug of 
p 12 fimiware for operating the disk controller circuit and performing a plurality of disk functions 
Ij 13 according to a script, wherein the plurality of disk fimctions comprise interaction of the 
^ 14 read/write model, the electromechanical model, the disk controller design base and the controller 



m 15 environment. 

5^ 16 The plurality of disk functions may be performed at a time-scaled rate and the thne-scaled 

^ 17 rate maintaining an accurate relative time relationship between the disk functions performed 

W 18 under direction of the script, and a real-time performance of the disk functions. The disk 

19 functions may be performed at a plurality of environmental and/or process limits and the models 

20 and the design base may be made to operate according to their predicted behavior at the 

21 environmental or process limits. 

22 The foregoing and other features of the invention are described in detail below and set 

23 forth in the appended claims. 

24 BRIEF DESCRIPTION OF THE DRAWINGS 

25 Fig. lA is a high-level block diagram of a presilicon disk model, according to an 

26 embodiment of the present invention. 

27 Fig. IB is a diagram of a presihcon disk model, according to another embodiment of the 

28 present invention. 



Y:\K:35A\A0900-A0999\A0912\DOC\912paf.doc 



Page 2 of 17 



PATENT 
ATTY DOCKET K35A0912 



1 



Fig. 2 is a data diagram of a solid-state disk, according to an embodiment of the present 



2 invention. 



3 



Fig. 3 is a diagram of an electromechanical model of a head actuator assembly coupled to 

4 the present solid-state disk and a model of the disk controller, according to an embodiment of tiie 

5 present invention. 

6 Fig. 4 is a block diagram of an error injection and detection mechanism, to an 

7 embodiment of the present invention. 

8 Fig. 5 is a diagram of chamel error detection mechanism, according to an embodiment of 

9 the present invention. 

10 Fig. 6 is a flowchart of a method for verifying the design of a disk controller circuit to be 
p 11 incorporated into a targeted disk drive, according to an embodiment of the present invention. 

§ 12 DESCMPTION OF THE PREFERRED EMBODIMENTS 

"^1 13 A method of emulating a new disk drive design in software as well as programmable 

Iff 

If 14 hardware includes the use of, for example, Complex Programmable Logic Devices ("CPLDs") 

^ 15 such as Field programmable Gate Arrays (hereafter, "FPGAs") that are programmed to emulate 

S 16 one or more components of a magnetic hard disk drive. Design emulation can help to reduce 

W ■ 

ill 17 time to market and save turns of silicon. Indeed, design emulation can accelerate product 

^ 18 development in advance of a stable platform and can improve product quahty by testing earlier 

19 and longer in the product cycle. 

20 Fig. 1 A is a high-level diagram of a presilicon disk model, according to an embodiment 

21 of the present invention. As shown therein, the present disk model 100 includes a solid-state 

22 disk 102 and a controller 105. The present soUd-state disk 102 may be coupled to a host 101 

23 (such as a personal computer, for example) via a host bus comiector (not shown) for the transfer 

24 of commands, status and data. The host 101 may issue read and/or write commands, as dictated 

25 by the execution of a software script for performing disk functions. The solid-state disk 102 is 

26 coupled to a model of a controller 105 according to the present invention, also coupled to the 

27 hosit 101. 

28 Fig. IB is a diagram of the presihcon disk model 100 of the present invention, according 
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to another embodiment thereof. As shown therein, the solid-state disk 102 may be coupled to the 

2 controller 105 through a digital to analog controller (hereafter, "DAC") 103 that provides analog 

3 read data to a read/write channel model 104 that is coupled to the controller 105 via an Non 

4 Return to Zero (NRZ) interface, for example. The emulated channel 104 may, for example, 

5 employ partial response maximum likelihood ("PRML") coding techniques, although the present 

6 invention may be practiced with equal advantage using other coding techniques. As suggested 

7 by the dashed line of reference 145, the channel 104 and the controller 105 may be embedded in 

8 a single integrated circuit. The host interface and disk controller (hereafter, "HEDC") model 105 

9 according to the present invention provides formatting, error detection and correction of disk 

10 data, responds to commands from the host 101 and stores data that is transferred between the 

11 soUd-state disk 102 and the host 101. The channel 104 is also coupled to the solid-state disk 102 
1^ 12 to provide the solid-state disk 102 with digital write commands. 

§ 13 Fig. 2 is a data diagram of a solid-state disk 102, according to an embodiment of the 

^ 14 present invention. The sohd-state disk 102 is most useful when it enables the emulation of the 

15 exact timing of a real disk drive. Indeed, it is important that the emulation of the reading and 

16 writing of data to the solid-state disk 102 occurs at the same timing as such drive functions 

17 would in a real drive. This enables accurate testing of the firmware 1 14 (which is preferably the 

18 same firmware as a real drive or the same firmware that is to be incorporated in the resultant real 

19 drive) and other contix)ller features that are dq)endent upon such timing. Toward that end, the 

20 sohd-state disk 102 includes a data memory 108 for storing data, a servo memory 1 10 for storing 

21 servo wedge data, a tuning memory 112 for storing timing data, a state machine 106 and a 

22 transfer conti'ol 107. The transfer control 107 interfaces with the HIDC conti-oller 105 through a 

23 read/write channel interface. The HIDC controller 105 is controlled by fmnware 1 14, which is 

24 also coupled to the servo memory 110 and to the timing memory 112. A state machine 106 

25 confrols the access by tiie transfer control 107 to the timing memory 112. Togetiier, the soUd- 

26 state disk 102, the host 101 (including the script files running thereon), the firmware 114 and the 

27 electromechanical model 302 (described relative to Fig. 3) provide a controller environment to 

28 support execution and debug of the firmware 114 for operating the disk controller 105, as 

29 described in detail below. 
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1 To enable the solid-state disk 102 to emulate a variety of disks, data formatting, spindle 

2 motor speeds and other disk and/or drive characteristics, the data memory 1 08, the servo memory 

3 110 and the timing memory 1 12 are preferably separate and distinct memories. Alternatively, the 

4 memories 108, 110 and/or 112 may be embodied as independently loadable areas of a single 

5 memory device. In this mainer, the data memory 108 stores only the data to be written to and 

6 read fiom the sohd-state disk 102. The data memory 108, preferably does not store any sector, 

7 zone or timing information, but only the raw data written to or read from the disk 102. The data 

8 stored in the data memory 108 is preferably raw, frequency insensitive data. The data memory 

9 108 may be or may include Dynamic Random Access Memory (hereafter, "DRAM"), such as a 

10 dual port Synchronous DRAM (hereafter, "SDRAM"), which is orders of magnitude faster than a 

11 real magnetic disk drive. The solid-state disk 102 may include, for example, 512 Mbytes of 
1^ 12 SDRAM storage for storing disk data that may be accessed during modeling operations. Fast 
Q 13 accesses to timing and servo data stored in SDRAM (or in RAM including some other 
^ 14 technology) enable time scaling the operation of the sohd-state disk 102 faster than real time. 

15 Moreover, the disk functions emulated on tiie solid-state disk 102 may be performed at a 

^16 plurality of environmental and/or process limits. This enables the designer to ascertain the 

^ 17 drivers most error prone areas and to predict where the resulting real magnetic hard drive might 

5 18 fail.. The models of the solid-state disk 102, the controller 105, the spindle motor model 316 and 

^ 19 the VCM head model 306 may be configured to operate according to their predicted behavior at 

Gi 20 the environmental and/or process limits. In turn, this enables the drive design and validation 

^ 21 team to selectively stress the controller 105, channel 104 and/or solid-state disk 102 faster than a 

22 real drive to spot failures. 

23 The data memory 108 should be sufficient large to test the writing and reading of large 

24 blocks of data without the need to repeatedly re-write the same tracks to write large blocks of 

25 data to the disk 102, However, the data memory 108 need not be as large as would be necessary 

26 to store a number of tracks equal to those present on an actual spinning disk. Indeed, a very large 

27 memory would be needed to store a clock-by-clock image of each track of a real disk drive. 

28 Moreover, the drive firmware would then have to be modified to accommodate such a clock-by- 

29 clock image of each track. Instead, a limited and selectable number of unique tracks may be 

30 provided such as, for example, 250 unique and individual tracks. These tracks may be mapped to 
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1 (through appropriate accesses to the servo memory 110 and the timing memory 112) and look 

2 like any track on any zone of a real spinning disk of a magnetic disk drive. In addition, one or 

3 more default tracks may be provided, thereby enabling the HIDC 105 to emulate seeking to and 

4 following any track, to allow the VCM and head actuator model 306 to emulate the behavior of a 

5 real disk drive. When the reading and writing commands issued by the HIDC controller 105 

6 have written or read from all 250 tracks, the default track(s) may be configured (through 

7 appropriate accesses to the servo memory 1 1 0 and the timing memory 1 12) to resemble any track 

8 at any zone frequency of an actual spuming disk. 

9 The servo wedge data may be stored as servo wedge data tables in the servo memory 110 

10 and the timing data may be stored as timing data tables in the tuning memory 1 12. These tables 

11 may be generated using a standard spreadsheet computer program (runmng on the host 101, for 
example) and loaded within the memories 110, 112. The servo wedge data tables may include 

13 data drawn to the track ID, wedge number, servo sync word and the head number, for example. 

14 The timing memory 1 12 may store these values as Hard Sector Descriptor Tables (HSDT) - or an 
B 15 equivalent structure - for different frack formats. The burst data may be externally generated, as 

16 shown in Fig. 3, for example. The timing data tables are scanned by the HIDC controller 105 

17 and tell the controller 105 where the transfers of the raw data stored in tiie memory 108 occur 
W 18 around the servo wedges stored in the memory 1 12. This is necessary to emulate a real disk in 

19 which the sectors are frequently spUt across servo wedges. The timing tables in the timing 

20 memory 1 12 and the servo wedge data stored in the servo memory 1 10, in effect, are configured 

21 to enable the HIDC controller 105, through firmware 1 14, to apply the raw data stored in the data 

22 memory 108 to a variety of frequencies, depending upon the disk format that is being emulated 

23 and upon the sector and track of the data accessed by the HIDC 105. Changing the format of the 

24 emulated disk, therefore, becomes a simple matter of re-loading the timing data tables and servo 

25 data tables stored in the timing memory 112 and the servo memory 110, respectively. The 

26 mapping of each of the unique fracks to unique and selected cyhnders may be readily changed by 

27 swapping in new timing tables into the timing memory 1 12. 

28 To enable the HIDC controller 105 to be fiilly tested across different timings and 

29 potential error conditions, the present invention provides for timing windows having selectively 
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variable boundaries. Such timing windows may be selectively opened and selectively closed 

2 (i.e., the width of the timing windows is selectable) around the expected timing of events such as 

3 the detection of sync marks and/or other data structures on the solid state disk 102. Indeed, to 

4 fully test the controller 105, it is useful to have the ability to move such timmg windows around 
an expected timing of the corresponding signal and to monitor the resultant perfomiance and 



5 



5 5?? 



6 behavior of the controller 105 and the drive firmware 1 14. For example, the timing boundaries 

7 for such signals as Sgate (Seek gate signal), Wgate (Write gate signal) and Rgate (Read gate 

8 signal) may be varied at will for exhaustive timmg boundary testing of the controller 1 05 . 

9 The servo memory 110 and the timing manory 1 12 enable a high degree of control over 

10 the error injection process that is not possible using a real drive. For example, to test the 

11 firmware 114, the values stored in the servo memory 110 may be manipulated by changing a 
1^ 12 selected number of servo wedges to include incorrect track identifiers. The firmware 114 may 
Q 13 then be observed to ascertain its behavior when it encounters such errors. Other errors may be 
P 14 injected, such as incorrect wedge numbers, for example. Fig. 4 is a block diagram of an error 
IM:\5 injection and correction mechanism, according to an embodiment of the present invention. 

16 According to the present invention and as shown therein, a software script may be stored on and 

17 executed by the host 101 to corrupt selected bytes of sector track data (among other error 
y 18 injection possibiUties). For example, bytes 102, 305 and 503 of a sector ti:ack stored in sector 

19 data memory 402 may be corrupted in the host 101 by changing the bit values of these bytes to 1 

20 (all other bytes being zero) and stored in the host in error data memory 404. The sector track 

21 data 402 may then be transported across the bus 418 and copied in the solid-state disk 102 at 

22 corresponding sector and error data memories 406 and 408, respectively. The bus 418 is 

23 preferably sufficiently wide to incorporate adjacent original track data and error ti-ack data. The 

24 stores 402, 404, 406 and 408 advantageously include SDRAM and tiie bus 418 may be an 

25 SDRAM bus. 

26 Data streams firom the sector data 406 and tiie error data 408 of the solid-state disk 402 

27 may then be passed through an XOR gate 410. The logical XORing of these two data streams 

28 causes, in the current example, bytes 102, 3 15 and 503 of tiie track data to be corrupted (logical 

29 I's become logical O's and vice-versa) on tiie Non Return to Zero (hereafter, "NRZ") bus 420. hi 
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effect, the original track data may be corrupted, in real time, in a controllable and predictable 

2 manner and programmable errors may be injected into the sohd-state disk 102, in real time or in 

3 a time-scaled (faster or slower than real time) manner. The NRZ corrupted data on the NRZ bus 

4 420 may then passed through an error correction engine 416 within the controller 105 to correct 

5 the corrupted NRZ sector data. The resulting corrected data stream output from the error 

6 correction engine 416 of the controller 105 is compared, in the host 101 at 422, to the original 

7 sector data stored at 402 in the host 101, to detect any errors in the corrected data. The 

8 performance of the error correction engine 416 may be talUed within the host 101 by a counter 

9 (not shown). According to an embodiment of the present invention, each sector data track within 

10 the soUd-state disk 102 is associated with an sector error track, making it possible to freely inject 

11 and detect a variety of errors in any of the data tracks of the soUd-state disk 102 and to test the 
5^ 12 controller's error correction engine 416 under a variety of error conditions. The error mjection 
|l 13 and detection may be driven according to an executable script stored and running on tiie host 
§ 14 101. The script or scripts may also provide for carrying out a plurality of disk functions 

15 inchiding, for example, reading, writing, seeking, track following and the like while irijectmg and 

16 detecting a wide variety of errors. More specifically, software running on tiie host 101 may be 



ill 



5 17 



configured so as to automatically set up and monitor the parameters of the tests to be conducted. 

§18 For example, the software on the host 1 01 may load the FPGAs on the solid-state disk 102 and/or 

^19 the contiroUer 105, set the desired clock frequencies on the soUd-state disk 102 and the controller 

S 20 105, be configured to selectively upload and download the contents of the memories on the solid- 

■ 21 state disk 102 and the controller 105, the setting and reading of hardware registers on the solid- 

22 state disk 102 and the controller 105 (to enable the changing of the timing boundaries of timing 

23 windows for the Sgate, Rgate and/or Rgate signals, for example) and to enable a hard reset of the 

24 solid-state disk 102 and the controller 105, among other exemplary fimctions. The software 

25 running on the host 101 may ftirflier enable test automation through a script mterpreter capable 

26 of, for example, nested automation of script files, nested loops, running a single script file an 

27 unlimited number of times, loop on error, loop forever and/or stop on error fimctions, for 

28 example. 

29 It is necessary to maintain both sector data tracks (such as shown at 406) and error data 

30 tracks (such as shown at 408) in the solid-state disk 102 because the variable length Error 
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1 Correction Code (ECC) is unknown until the data is passed through the ECC error correction 

2 engine 416 of the controller 105. Changes cannot be made to the sector data 406 in the host 101 

3 prior to loading the sector data since any change would impact the ECC. Therefore, the loadable 

4 error data stored in the error data memory 404 is used to induce errors in the sector data stored in 

5 the sector data memory 402 when reading back the adjacent error tracks 408. The solid-state 

6 disk 102 may also include a zone register 412 and a clock generator 414. The zone register 412 

7 provides clock frequency data to the clock generator 414 to produce a data transfer rate 

8 appropriate for the zone of the disk being error tested. This enables tracks in any zone to be 

9 changed at will to test the controller's correction engine 416 on various regions of the disk as if 

10 the solid-state disk 102 were real, physical spinning media. The clock generator 414 may be 

11 progranmiable and may advantageously provide two independently programmable clocks. For 

12 example, the clock generator may provide clock signals from 390 KHz to 120Mhz, although a 

13 wider range of clock frequencies may be readily implemented within the context of the present 

14 invention. 

15 In addition to supporting confroller error detection and correction, the present invention 

16 supports real time testing of the channel 104. Fig. 5 is a diagram of such a channel error 

17 detection mechanism, according to an embodiment of the present invention. As shown therein, 

18 the channel error detection mechanism 500 mcludes the host 101, the solid-state disk 102, the 

19 confroller 105, the channel 104, an error counter 512, an XOR logic gate 510 and an Arbitrary 

20 Waveform Generator (hereafter, "AWG") 502. Digital data (such as digital servo data, for 

21 example) is generated within the host 101 and passed to a Digital Signal Processmg ("DSP") 

22 program (such as MatLab®, for example) runnmg within the host 101, which sends the data to 

23 tiie AWG 502. The digital data sent to the DSP is also sent to the solid-state disk 102 and stored 

24 in memory therein (such as data memory 1 08, for example). The digital data from the host 1 01 is 

25 stored in RAM 504 and converted into analog form by DAC 506. The analog output of DAC 

26 506 is then decoded by the channel 104 to attempt to recover the digital data output from the 

27 DSP within the host 101. The decoded output of the channel 104 is compared to the digital data 

28 stored within the memory of tiie sohd-state disk 102. The NRZ output of the XOR gate 510 may 

29 be sent to the memory within the solid-state disk 102, to an error counter 512 and to the HIDC 

30 confroller 105. The output of the AWG 502 (which may be characterized as servo data) is also 
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1 sent to the controller 105. As long as the demodulated output of tiie channel 104 is identical to 

2 the digital data stored in the memory of the soUd-state disk 102, the output of the XOR gate 510 

3 will not be asserted. If, however, the output of the channel 104 differs from the value stored in 

4 the memory of the sohd-state disk, the output of the XOR gate 5 10 is asserted, the error counter 

5 512 incremented and the error stored in the memory of the solid-state disk 102. Unlike the error 

6 injection mechanism detailed relative to Fig. 4, the channel error detection scheme detailed 

7 above and shown in Fig. 5 uses two identical (unless the channel 104 generates error) data 

8 streams that are compared via the logical XOR gate 510. 

9 If a problem can be simulated, its potential solutions may be implemented by changing 

10 the parameters of the models aid/or by changing the models themselves. Once a solution is 

1 1 implemented in tiie model, its physical counterpart implementation should be apparent in the real 

12 world. This process of simulating a problem and solving the problem using an accurate model of 

13 the physical systerh allows designers to implement and validate a designed change must faster 

14 and in a less costly manner than turning silicon. Using such models, in turn, allows the drive's 

15 firmware to be developed at an early stage, and the design frozen onto the physical platform 

16 much sooner than would otherwise be possible. This is believed to significantly reduce the time 

17 to market of the resultant drive. 

1 8 The present invention may be used as desaibed above, to emulate the operation of a drive 

19 in which the read/write head is always on track. Such may be desirable if the testing and 

20 vahdation being carried out is to be limited to, for example, testing the ECC error correction 

21 engine 416 or selected portions of the operation of the firmware 114. This may allow time 

22 scaling the emulation to run much faster than a real disk drive is capable. However, tiie present 

23 invention also provides a complete electromechanical model of the head assembly, in order to 

24 fully test and validate the design. 

25 Fig. 3 is a diagram of an electromechanical model 302 of a head actuator assembly 

26 coupled to the present solid-state disk and an emulation of the disk contix)ller 105, according to 

27 an embodiment of the present invention. Fig. 3 includes a simplified diagram of the HIDC 

28 controller 105, as well as the solid-state disk 102, to illustirate tiie data paths and interactions 

29 thereof with the electromechanical model 302. As shown, the electromechanical model 302 may 
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1 include (at least) an actuator model 330 and a spindle model 332. As shown, the actuator model 

2 330 may include a Voice Coil Motor (hereafter, "VCM") and Head Stack Assembly (hereafter, 

3 "HSA") model 306, a head position to burst data translator 308, as well as a nimiber of look up 

4 tables 310, 312, 314 (and/or optionally others, not shown) that model different mechanical and/or 

5 electrical characteristics of the HSA of the modeled drive. The spindle model 332 may include a 

6 spindle motor model 316 and a look up table 317 stores spindle motor characteristics that may be 

7 applied to the spindle motor model 316. Examples of such spindle motor characteristics include 

8 the torque and friction characteristics of the spindle motor. The look up tables 310, 312, 314, 

9 316, 317 (and/or optionally others) may be changed at will to vary the simulated behavior of the 

10 HSA and/or of the spindle motor. The same structure of model and look up tables may be 

1 1 implemented to selfectably and variably model any other mechanical or electromechanical system 

12 of the simulated drive, the present invention not being limited to the models and look up tables 

13 shown in the figures. The spindle motor model 316 is controlled by the HIDC controller 105 in 

14 the same manner as a real spindle motor would be. Indeed, the spindle motor model 316 may 

15 send the HIDC controller 105 a signal resembling a square wave that is representative of the back 

16 EMF pulses that would be generated by a real spindle motor. For the controller's jfirmware's 

17 point of view, there is preferably no difference between controlling the real spindle motor and 

18 controlling the model 316 thereof In other words, the controller firmware need not be modified 

19 to control the spindle motor model 316. 

20 According to the present invention, the digital serial command data 318 generated by the 

21 controller 105 (through the servo and controller firmware) is input to the VCM and Head model 

22 306 of the electromechanical model 302. The VCM and HSA model 306 takes signal 318 and 

23 processes it and causes the emulated HSA to behave in the same manner and timing (or similar 

24 manner and timing, depending upon the accuracy of the simulation models) as would a physical 

25 head stack assembly. The electromechanical model 302 then outputs burst data at 320, which 

26 burst data represents the position of the read/write head over the emulated disk, integrated over 

27 time. For example, the burst data output from the head position to burst data translator 308 may 

28 represent the next position of the simulated head over the simulated disk (when simulating the 

29 track following disk fimction) or the track ID (when simulating the seek disk fimction). The 

30 electromechanical model 302, together with the soUd-state disk 102 and the HIDC controller 
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1 model 105 and associated hardware and software allow the same firmware 1 14 to be used in the 

2 present emulation as would be used in a real, physical drive. Firmware 1 14, therefore, is a full 

3 firmware set, which enables the disk to be designed, validated and tested with the same (or only 

4 slightly modified) firmware that will ultimately control the resultant physical drive. 

5 The electromechanical model 302 may, according to an embodiment of the present 

6 invention, be implemented as a Field Programmable Gate Array (hereafter, "FPGA") such as 

7 manufactured, for example by Xilinx, Inc. of San Jose, CA. For example, the Xilinx XVC series 

8 of FPGAs may be employed for both the electromechanical model 302 and to model the solid- 

9 state disk 102. FPGAs are Static Random Access Memory ("SRAM") loadable, which means 

10 that the characteristics of the electromechanical model 302 may be changed at will. The model 

11 302 is based upon mathematical simulation models 322 that may be developed usuig 

12 mathematical simulation software packages such as, for example, MathCAD® or MatLab®. 

13 After a translation and compile steps shown at 324, Verilog code (or some other Hardware 

14 Description Language ("HDL") code) is generated at 326, which may thai be used to program 

15 the FPGA, as shown at 328. Any of a number of utilities known to those of skill in this art may 

16 be employed to convert the behavioral models 322 developed using the mathematical simulation 

17 software package to HDL code. In the same manner, Verilog code may be developed that 

18 models the behavior of the HIDC controller model 105 and provide a disk controller design base 

19 for defining the constituent integrated circuit elements of the disk controller model 105. 

20 The VCM and HS A model 306 may include time integration models based on differential 

21 calculus. The VCM & HSA model 306 may be advantageously embodied, for example, as a 

22 Finite Impulse Response (hereafter, "FIR") filter with tap weights to vary the characteristics of 

23 the FIR filter. The tap weights, according to an embodiment of the present mvention, may be 

24 stored in tables 3 10, 3 12, 3 14 (and/or others). In this manner, the VCM & HSA model 306 may 

25 be configured to generate tiie deshed waveform and the tables 310, 312, 314 (and/or others) may 

26 be utilized to store table look up values that selectively modify the generated waveform. For 

27 example, the table 310 may store values related to a selected HSA static or dynamic 

28 characteristic such as values associated with the torque exerted on the HSA by the flex cable that, 

29 in a real drive, carries the signals from the HSA to the printed circuit board containing the HIDC 
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1 



controller 105. Another table 312 may store values related to the resonance values of the HSA 

2 and table 314 may store values related to the torque experienced by the VCM of the actuator 

3 assembly, as the coil of the VCM moves into and out of the magnetic fields of tiie permanent 

4 magnets of the drive's top and bottom VCM plates. Other characteristics of the HSA may be 
stored in additional tables, each of which may act as tap weights to the FIR filter of the VCM and 



5 



6 HSA model 306. The accuracy of the simulation (and/or of the resultant hardware) may be 



7 



determined by, for example, creating Bode (for example) plots of the simulation and creating 

8 corresponding Bode plots for the hardware incamation of the drive under development or test. 

9 By correlating the Bode plot(s) generated from the simulation from the Bode plot(s) generated 

10 from the real hardware drive, the differences between the real and simulated drives may be fully 

1 1 characterized. A programmable external clock 304 is provided provides a programmable timing 

12 reference, which allows the system to be time scaled, if desired. 

13 Advantageously, the pre-sihcon validation method according to the present invention 

14 includes hardware-accelerated emulation. The hardware-accelerated emulation is made possible 
W\ 15 by constructing the solid-state disk 102 and the electromechanical model 302 using FPGAs and 

in 

^ 16 SDllAMs, which enables the firmware to be run orders, of magnitude faster than conventional 

^ 17 Verilog® (or other hardware description language)-based simulations. 

H 18 Fig. 6 is a flowchart of a method for verifying the design of a disk controller circuit to be 

W 19 incorporated into a targeted disk drive, according to an embodiment of the present invention, 

fli 20 The targeted disk drive includes a read/write channel and a head actuator. As shown in Fig. 6, 

21 the present invention, according to an embodiment thereof, step S61 calls for emulating reading 

22 and writing of data in the read/write channel of a disk drive based upon a model 104 of the 

23 read/write channel. Step S62 calls for emulating the behavior of the head actuator during track 

24 seek and track following operations based upon an electromechanical model 302 of the head 

25 actuator. Next in step S63, a disk controller design base is provided for defining integrated 

26 circuit elements comprising the disk controller circuit and a controller environment is provided, 

27 at S64, to support execution and debug of firmware 1 14 for operating the disk controller circuit. 

28 Thereafter, as shown at S65, a selected disk ftinction or functions may be performed according to 

29 a script. The disk functions (e.g., read, write, seek, track following) may include interaction of 
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1 the read/write channel model, the electromechanical model, the disk controller design base and 

2 the controller environment. 

3 
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